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Abstract — This paper motivates the need for a formalism 
for the modelling and analysis of dynamic reconfiguration of 
dependable real-time systems. We present requirements that 
the formalism must meet, and use these to evaluate well- 
established formalisms and two process algebras that we have 
been developing, namely, Web^ and CCS dp . A simple case 
study is developed to illustrate the modelling power of these 
two formalisms. The paper shows how Web^ and CCS dp 
represent a significant step forward in modelling adaptive and 
dependable real-time systems. 



XeyHwds-Requirements, dynamic 
elling, analysis, verification 



reconfiguration, mod- 



I. Introduction 

Modern dependable real-time (DRT) systems are required 
to have greater flexibility, availability and dependability than 
their predecessors. One way of achieving this is through the 
use of dynamic reconfiguration techniques. A system can be 
implemented as a collection of configurations, where each 
configuration is a network of communicating components. 
Different configurations can be optimized for different ser- 
vices or operating conditions. Therefore, facilities for re- 
placing one configuration by another at runtime can increase 
the flexibility of the system. Runtime facilities for creating 
configurations that provide new services, and for removing 
configurations providing services that are no longer required, 
can reduce the downtime for maintenance; thereby increas- 
ing the availability of the system. Replacing an executing 
configuration when it exhibits erroneous behaviour with a 
valid configuration increases the system's reliability; and 
thereby increases its dependability. However, dependability 
is a combination of reliability and predictability, and ensur- 
ing predictability during dynamic reconfiguration is difficult. 
The main reason for the difficulty is the interaction between 
the application services that the system is required to provide 
to its environment and the reconfiguration services that the 
system must also perform in order to support its flexibility, 
availability and reliability. The interaction between the two 
kinds of service implies that neither can be analyzed in 
isolation. 

Existing research on DRT systems has largely concen- 
trated on system design and programming languages (see 



HI and 1121) rather than on formalisms and their methods. 
However, formal methods are important because they are 
useful in providing the strong guarantee of system correct- 
ness required for such systems. Furthermore, the formal 
research on DRT systems has focused on scheduling (see 
0, E| and J5J) rather than on computational models. 
As for the existing research on dynamic reconfiguration, 
it has either assumed mode changes to be instantaneous 
or has implicitly assumed the controlled environment can 
wait whilst the control system is reconfigured [6|. Both 
assumptions are unrealistic for DRT systems. For example, 
it is impossible to perform an instantaneous mode change 
in a distributed control system because a distributed system 
has no global state; and suspending or aborting application 
services during reconfiguration in an unstable 'fly-by-wire' 
aircraft would cause the aircraft to become unstable, and 
possibly suffer catastrophic failure. Thus, there is very little 
research on computational models with overlapping modes 
- the most appropriate form of dynamic reconfiguration for 
DRT systems. Therefore, the purpose of our research is to 
develop a computational formalism for DRT systems, in 
which interactions between application and runtime system 
activities can be modelled; and the model can be used to 
verify safety and liveness requirements of the system. DRT 
systems are typically used to maintain the stability of unsta- 
ble environments and to keep them under control. Therefore, 
they are characterised by time-critical concurrently executing 
activities with hard deadlines, small synchronisation toler- 
ances between events, and tight resource constraints. Hence, 
our formalism must be able to express both reconfiguration 
and real-time features of DRT systems, and must be able to 
verify both their functional and timeliness properties. 

Paper's Contribution and Structure 

This paper makes three contributions. First, it identifies 
requirements on a formalism for DRT systems that have 
overlapping modes. Second, it evaluates well-established 
formalisms against these requirements. Third, it briefly de- 
scribes two novel process algebras that we believe progress 
the state of the art in this field. The rest of the paper is 
organized as follows: section [II] describes a simple frame- 



work that illustrates the scope of the reconfiguration we 
are considering, and then identifies the structural, modelling 
and analysis requirements that a formalism targeted on the 
dynamic reconfiguration of DRT systems must meet. Sec- 
tion Hn] uses these requirements to evaluate well-established 
formalisms and identifies their strengths and weaknesses. 
Sections [IV] and [V] describe two formalisms we have been 
developing, and evaluates them against the requirements. 
Finally, Section|Vl]describes a simple case study to illustrate 
the modelling power of these two formalisms. 

II. Requirements on a Formalism for Dynamic 
Reconfiguration 

Reconfiguration of a DRT system typically involves 
changing one configuration - a network of communicating 
and concurrently executing components of the system - into 
another. Software components can also migrate between 
networked computers. The computers and their network 
constitute the hardware platform of the system, which does 
not change. We can represent the system using a simple 
framework (see Figure [TJ. The application layer consists of 
those components of the system and their communication 
connectors (i.e. objects and links) that are the focus of 
reconfiguration. The location layer (which does not change) 
is used to represent those components and connectors (i.e. 
nodes and channels) that are necessary in order to describe 
the migration of objects and links. Thus, reconfiguration can 
be represented as the creation and deletion of objects and 
links, and as changes in the mappings between objects and 
links, objects and nodes, links and channels, and links and 
nodes. 

It is important to notice that a method for reconfiguration 
is not included in the framework or in the requirements. 
This is because we believe that determining a method is the 
responsibility of the system designer, rather than the for- 
malist. As an analogy, the differential and integral calculus 
does not contain a method for designing car engines; but 
the calculus is still useful in this respect. These aspects have 
been properly discussed in Q. 

In order to be practicable, it must be possible to support 
the formalism with tools for both modelling and automated 
analysis. 

The requirements we have identified fall into three cate- 
gories: structure, modelling and analysis. The completeness 
of these categories can only be determined with respect to 
a full case study, which is beyond the scope of this paper 
(in Section [Vl] only a small example will be presented). 

Structural Requirements 

It must be possible to model components in a recursive 
and compositional way. To do this, models must be organi- 
zable in terms of units, with each component of a system 
expressible as a composition of one or more units, and each 
unit corresponding to only one component. This way, it 



should be possible to express independent reconfiguration of 
units, in the same way that components can be independently 
reconfigured. 

Modelling Requirements 

The formalism must be able to express the following: 

1 ) Reconfiguration of Components: it must be possible 
to express the creation, deletion and replacement of objects, 
and also the migration of objects between nodes (see Fig- 
ure H). 

2) Reconfiguration of Connectors: it must be possible to 
express the creation and deletion of links between objects. 

3) Application Behaviour: it must be possible to express 
the functionality of an application in terms of basic activities 
(such I/O, data transformation and data manipulation) and 
their composition using sequencing, parallelism, alternatives, 
iteration and recursion. 

4) Interference with Runtime Support: it must be possible 
to express interference between the application and recon- 
figuration activities of the system. The interference can be 
functional or temporal, and can occur in both directions. 
For example, functional interference can occur because the 
replacement of an object can change the output of the 
application; and conversely, the execution of an object that 
is to be replaced can change its state, and the reconfiguration 
activity must take this state change into account when 
replacing the object. Temporal interference is the effect on 
timing properties (such as execution time) of the concurrent 
execution of application and reconfiguration activities; and 
it can occur in the absence of functional interference. 

5) Real-Time Information: it must be possible to model 
concurrent activities in terms of their ordering, duration, 
communication, interrupts and memory usage for schedu- 
lability analysis. Clocks must also be modelled. 

6) Real-Time Restrictions: it must be possible to express 
restrictions arising from requirements or resource limita- 
tions, such as deadlines, computation times and bounds 
on synchronization. Since memory is limited, it must be 
possible to express restrictions on memory usage. 

7) Fault Tolerant Behaviour: it must be possible to 
express the failure modes of a system and their failure rates; 
and the way in which errors will be recovered. 

Analysis Requirements 

The main purpose of modelling is analysis. Therefore, 
we identified a number of analyses that must be supported 
by the formalism: the formalism must be consistent. That 
is, it must not be possible to prove both a statement and its 
negation; otherwise, the result of an analysis can be logically 
invalid. Critical properties of the system modelled using the 
formalism must be decidable. That is, the function evaluating 
these properties must be Turing computable [8|. If these two 
requirements are not met, it will not be possible to provide 
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Figure 1. Framework for Dynamic Reconfiguration 



automated tool support and the formalism will not be used 
in practice. 

Termination of critical activities must be decidable (see 
'Analysis Requirements' in Section [IV] for a discussion). 
That is, it must be possible to decide whether or not any 
activity will stop its execution. Deadlock detection must 
also be decidable. That is, it must be possible to decide 
whether or not two or more processes can wait indefinitely 
for each other in a cycle [9]. It must also be possible to 
decide whether or not activities can meet their deadlines 
with respect to a scheduling discipline. It must be possible 
to check whether or not data transformation and date ma- 
nipulation are type correct. It must be possible to perform 
reliability analysis using the failure modes and failure rates 
given in the model. 

III. Evaluation of Formalisms 

The requirements described above can be used to evaluate 
existing formalisms for their suitability for the modelling 
and analysis of dynamic reconfiguration of DRT systems. 
Lack of space prevents a detailed and comprehensive review. 
Therefore, we briefly review a selection of well-established 
model-based formalisms, process algebras, Petri nets and 
other formalisms, and identify their significant strengths and 
weaknesses. Notice that the parts dedicated to "Analysis 
Requirements" are more focused on the existing tool support 
for the specific formalism, since some of the properties 
described above are not always applicable (e.g. deadlock 
for sequential formalisms) or are obviously satisfied. 

A. Model-based formalisms 

There is a long tradition of methods in this category. The 
most famous are probably VDM [10], Z |QT|, B-method 
|[T2l and, lately, Event-B [ 1 3 1 . The mathematics underlying 
these formalisms are set theory and first order logic. The 
approach consists of modeling the system's state in terms of 
sets and functions, and modelling state transformation using 
operations (or events in the case of Event-B). Predicates 
are used to express invariant conditions on the state. In 
Z, the emphasis is on formal specification, whilst the B- 
method emphasizes the "method" itself. Both B and Event-B 



focus on the application of stepwise refinement (reification 
in VDM). That is, the verifiable transformation of an high- 
level formal specification into an executable program. 

Structural Requirements 

The VDM Specification Language (VDM-SL) and its 
extended form (VDM++) deal with structure in different 
ways: VDM-SL uses modules, whilst VDM++ (being object- 
oriented) uses classes with multiple inheritance. Thus, both 
can express structural information. Classical B and Event- 
B specifications are instead organized in machines that also 
impose a basic structure. 

Modelling Requirements 

Reconfiguration is not natively supported by these for- 
malisms, but it can be encoded with difficulty (as in Turing 
Machines). None of these formalism has been designed for 
reconfiguration. Also, real-time information and restrictions 
are not natively supported. Temporal extensions exist (e.g. 
temporal logic for Z), but they do not enable all the real- 
time requirements to be met. Fault tolerance is not natively 
supported, but many contributions exist in this field. The 
Deploy project (www.deploy-project.eu) is addressing these 
issues for Event-B. 

Analysis Requirements 

Model-based formalisms are mature, and they tend to 
have extensive tool support. For example, Overture for VDM 
(www.overturetool.org) and Rodin for Event-B (www.event- 
b.org). They have facilities for type checking, verifying 
partial correctness of a design, and checking termination. 
However, they are more targeted on sequential systems, and 
(therefore) properties characteristic of concurrent systems, 
such as deadlock freedom, are not directly addressed. This 
does not mean that they cannot be used to model concurrent 
systems at all. In particular, Event-B can represent interac- 
tive systems. However, events are atomic and are associated 
with an interleaving semantics without interference. 

B. Process Algebras 

Model-based formalisms are mainly concerned with func- 
tional properties and sequential behavior. In contrast, process 
algebras are concerned with interaction between concurrent 
processes. Among the original methods in this field, we can 
mention CSP fl4) and CCS [15]. Mobile process algebras 
(e.g. Milner's 7r-calculus |16|) represent a further develop- 
ment by addressing mobility. 

Structural Requirements 

The common structural unit of all process algebras is a 
communicating concurrent process. Process algebras sup- 
porting a basic form of structuring do exist, although of a 
different nature if evaluated with respect to the requirements 
discussed in this paper. For example, the ambient calculus 
ifTTIl includes a notion of locations and mobility. Web^^ is 



described later in this paper with the structure it imposes on 
the 7r-calculus. 

Modelling Requirements 

Mobile process algebras like the 7r-calculus are interesting 
because of their treatment of component bindings as first 
class objects, which enables link reconfiguration to be ex- 
pressed simply. Although proper component reconfiguration 
is absent, the reconfiguration mechanism on which the tt- 
calculus is built already represents a seminal form of what 
is described in this paper. Extensions to support real-time 
and fault tolerance are an active area of research. 

Analysis Requirements 

The weakness of this category of language is tool support. 
Although different bisimulations have been defined and 
tailored to specific needs, tool support is still limited. It 
is worth mentioning TyPiCal, a type-based static analyzer 
for the 7r-calculus [18]. TyPiCal is able to provide four 
different kinds of program analyses and transformations: 
lock-freedom analysis (certain communications or synchro- 
nizations will eventually succeed), deadlock-freedom analy- 
sis, useless-code elimination (it removes sub-processes that 
do not affect the observable behavior of the process), and 
information flow analysis. The type system is extended in 
such a way that channel types carry information on how 
channels are used. This allows a type inferencer to obtain 
information about the behavior of a process. As a drawback, 
the expressive power of the type system is limited. 

C. Petri Nets 

Petri nets [19| are a graph-based formalism to represent 
concurrency. They are a mathematical formalism, but they 
also come with an appealing graphical notation in the 
style of UML activity diagrams l20l . To the best of our 
knowledge, Petri nets were the first formalism for describing 
concurrency. A formal account of Petri nets in the form of 
a survey can be found in ETl . 

Structural Requirements 

Structural information like modules is not natively ex- 
pressible in Petri nets. Although it is a suitable formalism 
to express parallel and distributed systems, for a long time 
it did not fully support compositionality, and this deficiency 
prevented its wide use in large real-world applications. 
The recent 'hype' on formalisms for verification of Web 
Services composition lead to some work done in this field 
in opposition to the process algebra approach. Indeed a 
big debate arose in the recent years to this regard and it 
is well explained in 11221 and in the conclusions of ll23l . 
Some work for enhancing Petri nets compositionality in 
other contexts has been done (a survey in [24]) and also 
work on modularization and Petri nets do exist [25] but we 
are not aware of applications. 



Modelling Requirements 

Petri nets do not offer a native way for addressing dynamic 
reconfiguration, but extensions to the formalism have been 
presented to allow for an easy formalization of this feature. 
For example, reconfigurable Petri nets l26l are a subclass 
of net rewriting systems with the goal of enhancing the 
expressiveness of the basic model. Other approaches to 
model dynamic reconfiguration have been tried and shown 
through case studies [27|. The original version of Petri nets 
is not Turing complete but extension have been provided 
later to add expressiveness. 

Analysis Requirements 

Tool support for Petri nets benefited from decades 
of research on the topic (see www.informatik.uni- 
hamburg.de/TGI). Various kinds of Petri net are supported 
by tools, and many of these tools offer a practical and 
appealing graphical editor not offered by other formalisms. 
Animation and model checking are other useful features 
offered by some of these tools. Overall, it is probably not an 
exaggeration to say that, in comparison to process algebras, 
tool support for Petri nets have received much more attention 
from the scientific community. 

D. Other Formalisms 

We are aware of others formalisms that deserve attention. 
Here we will briefly mention some of those with their main 
features. 

The Chemical Abstract Machine (CHAM) EH exploits 
the chemical metaphor. That is, it follows an approach based 
on viewing software systems as chemicals whose reactions 
are rigorously controlled by specific rules. The original idea 
was to bridge the gap between Petri nets, which can be 
considered as abstract machines but lack expressiveness (in 
the basic version) and process algebras, which are more 
expressive but are intended as specification formalisms for 
distributed systems (rather than as abstract machines). It is 
also worth mentioning how the gap between calculi for con- 
current processes and languages for programming distributed 
and mobile systems is not really bridged by CCS or n- 
calculus, since their interactions are based on rendezvous, 
i.e. atomic and non-local, which is hard to implement fully 
in a distributed setting. Here is where CHAM finds its 
niche and it is very interesting for its ability to represent 
a system as a syntactic description of the static components, 
the molecules, and of a set of reaction rules describing how 
the system evolves dynamically. This already shows how a 
system is structured in the formalism and how some form 
of reconfiguration can be expressed. Furthermore, formal 
reasoning, for example about deadlocks, can be performed. 

Another attempt of combining pros and cons of different 
formalisms and bridging the gap between them is CSP||B 
11291 . The authors recognize that a system can be projected 
into two different dimensions, the dynamic view and the 



state view, and these projections have to be consistent. Thus, 
they combine B with a controller language able to drive a 
B machine and this controller language is (a subset of) CSP. 
In this way B is able to express requirements on the state 
of a system while CSP expresses the interactive behaviour. 
This approach should permit the exploitation of existing tool 
support for both CSP and B. CSP||B is interesting for the 
purpose of this paper since it combines the structure of B 
and it has the potential of exploiting mobility like the ir- 
calculus, although not in the basic version |30|. 

Notable tool support in this category is provided by 
UPPAAL - an integrated tool environment for modelling, 
validation and verification of real-time systems, modelled 
as networks of timed automata extended with data types 
(www.uppaal.com). 

IV. Web-Koc 

In OTI and 1321 , a unifying theory has been developed 
with the pragmatic intention of using it for encoding or- 
chestration languages behavior (WS-BPEL in particular) and 
verifying process equivalence. Certainly, the reconfigurabil- 
ity needs in that scenario are limited compared to the general 
case: processes can be rolled-back or compensated, fault 
handlers activated, but they cannot be dynamically deleted 
or created. Both in WS-BPEL and in the developed theory 
Web^ there is always the need of statically defining a 
syntactical proximity between the process responsible for the 
normal behavior and the one responsible for the 'abnormal' 
one. This means that the two processes have to be statically 
bound. More complex behavior can be certainly encoded 
and the problem circumvented but we still have noticed that 
this practice would represent a sort of unpleasant 'hacking' 
that it is still far from what we want to offer to the final 
user. Despite this, we still recognize one step forward with 
respect to previous formalisms for what concern inborn 
reconfigurable behavior. First, being Web^ based on the tt- 
calculus, it allows the same sort of flexibility of its ancestors, 
i.e. link passing. But it does more offering a reconfigurable 
behavior as a first class citizen. In fact, when compared 
to the ideal formalism — the cornucopia able to elegantly 
satisfy all the presented requirements — Web7Too appears 
still primitive but it contains, in a seminal form, many of 
those requirements. 

\Veb7Too is a conservative extension of the 7r-calculus 
where the workunit operator <]P ; Q) has been added. 
Here the normal behavior is expressed by the process P 
and the abnormal one by Q, while x is the "trigger" that 
allows to switch from one to the other. This "trigger" is able 
to activate Q during the execution of P if another parallel 
process x (output) requires it. The evolution of the parallel 
composition of an output and a workunit (according to the 
formal reduction semantics) is: x \ \P ; Q) x ^ \Q ; 0|> 
that, for technical reasons here omitted, will then behave 
like Q. 



We believe this formalism shows some elegance and 
it is able to integrate structural, modelling and analysis 
requirements. 

Structural Requirements 

WebTToo expresses information on the structure being the 
system organized in different workunits. The basic struc- 
tural unit is a process, and workunits are used to perform 
reconfiguration representing what is being changed and the 
change. They can be recursive (nested) and compositional. 
Each of the workunit could, ideally, reside in a different 
host and could be compiled and linked separately. Although 
it is a very basic mechanism for structural information it 
represents an improvement in comparison to the 7r-calculus. 

Modelling Requirements 

1) Reconfiguration of Components: reconfiguration of 
components is possible through workunits and handler acti- 
vation. In a WebTToo process behaviour and reconfiguration 
are represented by P (application) and the interaction be- 
tween x and the workunit, which produces the execution of 
the process Q "replacing" P (reconfiguration). 

2) Reconfiguration of Links: reconfiguration of links is 
inherited by the 7r-calculus and its notion of mobility (which 
is a basic form of dynamic reconfiguration). The 7r-calculus 
looks interesting because of its treatment of component 
bindings as first class objects, which enables dynamic re- 
configuration to be expressed simply. 

3) Application Behaviour: the functionality of an appli- 
cation in terms of basic activities are abstracted over in 
WebTToo. This feature is inherited from the 7r-calculus which 
has the purpose of representing process synchronization, 
communication and link mobility. Activities like sequence, 
parallel, alternative, iteration, etc. are expressible through 
encoding. This exercise has been done in [23| to encode 
WS-BPEL. This shows how Web7Too is expressive enough 
to be used to describe the application behavior. 

4) Interference with Runtime Support: interference be- 
tween the application and reconfiguration activities of the 
system is expressible through message passing and rendez- 
vous, as shown in the example above. The interference can 
only be functional, not temporal. 

5) Real-Time Information: it is possible to model concur- 
rent activities in terms of their ordering and communication, 
but duration is not expressible (at least in the untimed 
version). Memory usage is not expressible, whilst interrupts 
are natively supported. Clocks cannot be modelled. 

6) Real-Time Restrictions: Web7Too is not able to express 
restrictions arising from time and space limitation limita- 
tions. However, a timed version of the language has been 
presented (but not coping with real time). 

7) Fault Tolerant Behaviour: fault tolerance is a point 
in Web7Too when describing, for example, the WS-BPEL 
recovery framework [33] and it has been one of the main 
reason for its development. Failure rates are not expressible. 



Analysis Requirements 

\Veb7Too is a conservative extension of the 7r-calculus and 
can be encoded using it. The reason for developing a new 
formalism was not the nature of its expressiveness, but 
its pragmatics. As a consequence, consistency is inherited 
from the 7r-calculus. Termination, in the general case, is 
not decidable for Turing-complete formalisms, including 
the 7r-calculus. In practical cases, and with the necessary 
restrictions (e.g. by typing and syntax), termination can be 
ensured. An adequate discussion on this topic is in [34). 
The same holds for Web-Tr^. Decidability of termination is a 
theoretically well-known limit; when designing a formalism 
it is always a matter of practicality finding a compromise be- 
tween the expressiveness of the languages and the properties 
that can be decided. 

Looking at the other requirements, in \Veb7Too it is not 
possible to decide whether or not the activities can meet 
their deadlines with respect to a scheduling discipline. It is 
not possible to check whether or not data transformation 
and manipulation is type correct. It is not possible to 
perform reliability analysis using failure modes and rates. 
WebTToo comes with its tailored definition of bisimulation, 
i.e. a mathematical tool able to determine if two processes 
exhibit the same externally visible behavior. The proposed 
bisimulation is decidable for non-recursive processes and 
some properties are proved, as an example, in [31]. 

V. ccs dp 

CCS dp is the first version of a formalism that is being 
developed specifically for the modelling and analysis of in- 
teractions between application and reconfiguration activities 
in DRT systems E3- It is based on CCS EJ, extended 
with a single construct - the fraction process — in order 
to reconfigure processes. 

A fraction process -p- is used to replace and delete pro- 
cesses. On creation, the fraction -p- identifies any instance 
of a process matching the denominator process P with 
which it is composed in parallel, and replaces that process 
immediately and atomically with the numerator process P' . 
The matching can be either syntactic equality or a special 
kind of behavioural equivalence we have defined. 

The reduction semantics is given 

b y p\t- — > p ' and 

Q|-p- — > P' where P Q. If no matching process 
instance exists, the fraction continues to exist until such a 
process is created (or the fraction is itself deleted or re- 
placed). If there is more than one matching process instance, 
a non-deterministic choice is made as to which process is 
replaced. Similarly, if more than one fraction can replace a 
process instance, a non-deterministic choice is made as to 
which fraction replaces the process. Deletion of a process P 
is achieved by parallel composition with 4. If P progresses 
to R, then -p- will not replace R by P' (unless R matches 
P). Notice that a fraction process has no intrinsic behaviour; 



it performs a transition only when composed with a process 
that matches its denominator. 

The key strengths of CCS dp regarding dynamic recon- 
figuration of DRT systems are: its ability to separate and 
compose models of application and reconfiguration activ- 
ities, resulting in modular and terse models; expressing 
application and reconfiguration actions in the same form, 
so that their interleaving can be easily represented; and its 
simplicity in modelling process reconfiguration. The key 
weaknesses of CCS dp are: its lack of facilities for naming 
processes, and for modelling real-time and fault tolerance 
properties of a system. 

Structural Requirements 

The basic structural unit is a process. The parallel compo- 
sition operator (|) of CCS enables a process to be composed 
from parallel processes, and a process to be decomposed 
into parallel processes. The restriction operator {v) facil- 
itates process composition by scoping port names. These 
facilities are inherited by CCS dp . The semantics of fraction 
processes enables application and reconfiguration activities 
to be modelled separately, and then composed using | to 
enable reconfiguration to take place. Thus, fractions support 
modular structuring of a model. However, since there is 
no naming scheme for processes, identical instances of a 
process cannot be selectively reconfigured. 

Modelling Requirements 

1 ) Reconfiguration of Components: replacement and dele- 
tion of components are expressed as reconfiguration tran- 
sitions involving a fraction process. Component creation is 
expressed as process spawning (as in CCS). The granularity 
of process reconfiguration is a concurrent process, and any 
parallel composition of processes can be reconfigured. Pro- 
cess reconfiguration is atomic. Process migration cannot be 
modelled, since the location of a process is not represented. 

2) Reconfiguration of Links: this can be expressed using 
process reconfiguration; but it is clumsy. 

3) Application Behaviour: facilities for expressing this are 
inherited from CCS. A process can perform I/O actions 
(without value-passing), internal action, sequential action, it- 
erative action, and make a deterministic or non-deterministic 
choice between alternative actions. Concurrent processes 
execute with interleaved semantics and communicate syn- 
chronously. 

4) Interference with Runtime Support: this is expressed 
in terms of interleavings between the application transitions 
and the reconfiguration transitions of a process expression, 
and the resulting process expression shows the outcome of 
the interference. Temporal interference cannot be described, 
since CCS dp has no time model. 

5) Real-Time Information: this is inherited from CCS, 
and is limited. Concurrent processes and the order of ac- 
tions can be expressed, but not the duration of an action 



(which excludes schedulability analysis). The synchronous 
communication between processes is also unsuitable for 
DRT systems. Memory usage, interrupts and clocks are not 
modelled. 

6) Real-Time Restrictions: these cannot be expressed in 
CCS dp . 

7) Fault Tolerant Behaviour: there are no special facilities 
in CCS dp to express this. 

Analysis Requirements 

Work on the analytical aspects of CCS dp is in progress: 
proof of consistency is significant because of negative 
premises in some of the semantic rules of CCS dp . Proof 
of decidability of the bisimulation is significant for 
matching. It is important to identify a practically useful set of 
processes for which we can prove decidability, termination 
and deadlock freedom. However, schedulability analysis, 
type checking and reliability analysis are beyond the scope 
of CCS dp . 

VI. Case Study 

In this section, we illustrate the modelling power of 
Web7roo and CCS dp by means of a simple case study: a 
'stripped-down' sensor array (see Figure 2). 

The sensor array consists of a number of identical hard- 
ware sensors, each of which is handled by a separate soft- 
ware process; and a reconfiguration manager. To maximize 
the longevity of the array, only one sensor is active at a 
time; the other sensors are either dormant or 'burned-out'. 
The array operates by the software process of the active 
sensor sending its reading to the reconfiguration manager, 
which processes the reading. If the sensor starts to 'burn- 
out', it intermittently outputs an error signal that causes the 
reconfiguration manager to reconfigure the array by deleting 
the faulty sensor's software process, and creating a new one 
to handle a newly activated hardware sensor. All the software 
processes are non-terminating. 
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Figure 2. Simplified Sensor Array 



WebiToc Model 

Let S be a sensor software process. S behaves nonde- 
terministically - either correctly or erroneously. In the first 
case, S will end up executing itself (after 'garbage collec- 
tion' of pending messages); whilst in the second case, S will 
send a message e' (again after "garbage collection"). We 
define S in Web-Tr,^ as follows: S — vQ.eQ.S + eQ.vQ.e' 
Let R be the reconfiguration manager. R consists of a 
workunit with body S. In the erroneous case, the handler 
of the workunit in R will be activated and restore S itself, 
which in turn, can still behave correctly or erroneously. We 
define R in WebTToo as follows: R = \S ; S\ , \v\e 

The reductions in both the normal and erroneous cases 
are: 

Normal case: §v().e().S + eQ.vQ.e' ; S§ e , \ v |e 
^{eQ.S; %, |e ^ \S ; 

Erroneous case: \v().e().S + eQ.vQ.e' ; Sty e , \v \e 

CCS dp Model 

Let S be a sensor software process. S behaves either 
correctly (performing v) or incorrectly (performing e). We 
can define S as follows: S = v.S + e.S 
Let R be the reconfiguration process. R either lets S 
continue (when S behaves correctly), or replaces it with a 
different instance of S (when S behaves incorrectly). R is 
defined as follows: R = v.R + e.(-^j^) 

The reductions in both the normal and erroneous cases 
are: 



Normal case: S\R — > S\R 
Erroneous case: S\R 



S\R 



VII. Conclusions and Future Work 

In this paper, we have focused on reconfiguration with 
interference between application activities and reconfigu- 
ration activities in DRT systems. We have identified re- 
quirements on a computational formalism, and evaluated 
well-established formalisms (as well as our own) against 
these requirements. We have shown that none of the ex- 
isting formalisms provides full native support for dynamic 
reconfiguration. Some implicitly contain specific features 
that can be useful when treating systems that inherently 
show reconfigurable features; but none of them are entirely 
suitable for this category of problems (see Table 1). 

Other formalisms could also have been evaluated, but we 
decided to refer to Wermelinger's PhD thesis ll36ll . which 
shares our conclusion. Wermelinger takes the premise that 
a single formalism can never satisfy all the requirements 
in every situation. Therefore, he presents three approaches 
- each one making use of a different formalism. Each 



Formalism 


Structural granularity 


Support for Dynamic Reconfiguration 


Tool support 


Event-B 


Machine 


Not supported 


Rodin 


CCS 


Concurrent process 


Process creation 


Edinburgh Concurrency Workbench 


7r-calculus 


Concurrent process 


Process creation; link passing 


TyPiCal 


Petri nets 


Net 


Not supported 


Extensive tool support 


CSP B 


Machine 


Process creation, deletion, replacement; link passing 


Tools for CSP and B 


CCS d P 


Concurrent process 


Process creation, deletion, replacement 


None 


\Veb7roo 


Concurrent process 


Process creation, deletion, replacement; link passing 


None 



Table - ! 

State of the Art of Formalisms for Dynamic Reconfiguration 



approach has its own assumptions about the system, and 
each has its advantages and disadvantages. 

As self-criticism, we need to mention some problems with 
this paper that deserve further work: first, it has been asked 
how we can know that the list of requirements is complete. 
In fact, the completeness of a list of requirements can never 
be determined for a generic system, but only for a specific 
system. Second, the survey of formalisms is incomplete. 
This was unavoidable due to space restrictions. 

For future work, the members of the Reconfiguration 
Interest Group (RIG) at Newcastle are interested in exploring 
different aspects of dynamic reconfiguration. In order to 
achieve integration of our research, we will need a common 
framework. This framework should be formal in order to 
support dependability during dynamic reconfiguration: it 
should be able to model architectural configuration; express 
policies that must hold for a configuration; reason about 
properties of the configuration - for example, formally 
verify whether or not a policy holds for the configuration; 
model the process through which a system is reconfigured; 
and verify whether or not the process satisfies the safety 
and liveness requirements of the system defined over the 
reconfiguration interval. 

Acknowledgments 

This work is partly funded by the EPSRC under the terms 
of a graduate studentship. The paper has been improved by 
useful conversations with Gudmund Grov, Jeremy Bryans, 
John Fitzgerald, Cliff Jones and Michele Mazzucco. We 
also want to thank members of the Reconfiguration Interest 
Group (in particular, Kamarul Abdul Basit, Carl Gamble 
and Richard Payne), the Dependability Group (at Newcastle 
University) and the EU FP7 DEPLOY Project (Industrial 
deployment of system engineering methods providing high 
dependability and productivity). 

References 

[1] H. Kopetz. Real-Time Systems: Design Principles for Dis- 
tributed Embedded Applications. Kluwer Academic Publish- 
ers, Norwell, MA, USA, 1997. 

[2] A. Burns and A.J. Wellings. Real-Time Systems and Pro- 
gramming Languages: ADA 95, Real-Time Java, and Real- 
Time POSIX. Addison- Wesley Longman Publishing Co., Inc., 
Boston, MA, USA, 2001. 



[3] K. Tindell, A. Burns, and A. J. Wellings. Mode changes in 
priority pre-emptively scheduled systems. In IEEE Real-Time 
Systems Symposium, pages 100-109, 1992. 

[4] N. C. Audsley, A. Burns, R. I. Davis, D. J. Scholefield, and 
A. J. Wellings. Integrating optional software components 
into hard real-time systems. Software Engineering Journal, 
11(3): 133-140, 1996. 

[5] J. Montgomery. A model for updating real-time applications. 
Real-Time Systems, 27(2):169-189, 2004. 

[6] J. Kramer and J. Magee. The evolving philosophers prob- 
lem: Dynamic change management. IEEE Transactions on 
Software Engineering, 16(11): 1293-1306, 1990. 

[7] M. Mazzara. Deriving specifications of dependable systems: 
toward a method. In EWDC, 2009. 

[8] A. M. Turing. On computable numbers, with an application 
to the entscheidungsproblem. Proc. London Math. Soc, 
2(42):230-265, 1936. 

[9] D. Zobel. The deadlock problem: a classifying bibliography. 
SIGOPS Oper. Syst. Rev., 17(4):6-15, 1983. 

[10] D. Bjorner and C.B. Jones, editors. The Vienna Development 
Method: The Meta-Language, volume 61 of Lecture Notes in 
Computer Science. Springer, 1978. 

[11] J.-R. Abrial, S.A. Schuman, and B. Meyer. A Specification 
Language. Cambridge University Press, New York, NY, USA, 
1980. 

[12] J.-R. Abrial. The B-book: assigning programs to meanings. 
Cambridge University Press, New York, NY, USA, 1996. 

[13] J.-R. Abrial. Modeling in Event-B: System and Software 
Engineering. To be published in 2010. 

[14] C. A. R. Hoare. Communicating sequential processes. Com- 
mun. ACM, 21(8):666-677, 1978. 

[15] R. Milner. A Calculus of Communicating Systems. Springer- 
Verlag New York, Inc., 1982. 

[16] R. Milner. Communicating and Mobile Systems: the Pi- 
Calculus. Cambridge University Press, 1999. 

[17] L. Cardelli and A.D. Gordon. Mobile ambients. Formal meth- 
ods for distributed processing: a survey of object-oriented 
approaches, pages 198-229, 2001. 



[18] N. Kobayashi. Typical: Type-based static analyzer 
for the pi-calculus, last accessed 19/04/2010. 

http : / / www . kb . ecei . tohoku .ac.jp. 

[19] C.A. Petri. Kommunikation mit Automaten. PhD the- 
sis, Fakultt Matematik und Physik, Technische Universitaet 
Darmstadt, 1962. 

[20] M. Fowler. UML Distilled: A Brief Guide to the Standard 
Object Modeling Language, Third Edition. Addison- Wesley 
Professional, 2003. 

[21] P. R. Manson. Petri net theory: a survey. Technical Report 
139, Computer Laboratory, University of Cambridge, June 
1988. 

[22] W.M.P. van der Aalst. Pi calculus versus Petri nets: Let us 
eat humble pie rather than further inflate the Pi hype, 2004. 

[23] R. Lucchi and M. Mazzara. A pi-calculus based semantics 
for ws-bpel. Journal of Logic and Algebraic Programming, 
70(1):96-118, 2007. 

[24] N.A. Anisimov and M. Koutny. On compositionality and 
petri nets in protocol engineering. In Fifteenth IF1P WG6.1 
International Symposium on Protocol Specification, Testing 
and Verification, 1996. 

[25] J. Padberg. Petri net modules. Journal of Integrated Design 
& Process Science, 6(4): 105-120, 2002. 

[26] M. Llorens and J. Oliver. Structural and dynamic changes 
in concurrent systems: Reconfigurable petri nets. IEEE 
Transactions on Computers, 53(9): 1147-1 158, 2004. 

[27] M. Lemmin, K. X. He, and S. Schatz. Dynamic recon- 
figuration of software objects using petri nets and network 
unfolding. In SMC'2000, Nashville, TN. 

[28] G. Berry and G.d Boudol. The chemical abstract machine. In 

Selected papers of the Second Workshop on Concurrency and 
compositionality, pages 217-248. Elsevier Science Publishers 
Ltd., 1992. 

[29] S. Schneider and H. Treharne. CSP theorems for communi- 
cating b machines. Formal Aspects of Computing, 17(4):390- 
422, 2005. 

[30] S.A. T. H. Schneider and B. Vajar. Introducing mobility into 
CSP||B. In AVOCS 2007. 

[31] M. Mazzara. Towards Abstractions for Web Services Com- 
position. PhD thesis, Department of Computer Science, 
University of Bologna, 2006. 

[32] M. Mazzara and I. Lanese. Towards a unifying theory for 
web services composition. In WS-FM, pages 257-272, 2006. 

[33] N. Dragoni and M. Mazzara. A formal semantics for the ws- 
bpel recovery framework - the pi-calculus way. In WS-FM' 09, 
Springer Verlag, 2009. 

[34] D. Sangiorgi. Termination of processes. Mathematical 
Structures in Computer Science, 16(1): 1-39, 2006. 



[35] A. Bhattacharyya and J. S. Fitzgerald. Development of a 
formalism for modelling and analysis of dynamic reconfigu- 
ration of dependable real-time systems: A technical diary. In 
SERENE 2008. 

[36] M. Wermelinger. Specification of Software Architecture 
Reconfiguration. PhD thesis, Universidade Nova de Lisboa, 
1999. 

Appendix 
Summary of Requirements 
Model Structuring Requirements 

Unit encapsulation, unit compositionality, unit naming. 

System Modelling Requirements 

• Reconfiguration of Components: component creation, 
component deletion, component replacement, compo- 
nent migration. 

• Reconfiguration of Links: link creation, link deletion. 

• Application Behaviour: input, output, calculation, data 
model, state update, control structures (sequence, par- 
allel, alternative, iterations, recursion). 

• Interference with Runtime Support: functional interac- 
tion, temporal interaction. 

« Real-Time Information: time model, memory model, 
communication model, concurrency model, interrupt 
model. 

• Real-Time Restrictions: scheduling restrictions, syn- 
chronization restrictions, memory restrictions. 

• Fault Tolerant Behaviour: fault models, error recovery. 

Analysis Requirements 

Consistency, decidability, termination, deadlock freedom, 
scheduling feasibility, type checking, reliability analysis. 



